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ABSTRACT 

Internet of Things (IoT) will create a cyberphysical world 
where all the things around us are connected to the Inter- 
net, sense and produce "big data" that has to be stored, 
processed and communicated with minimum human inter- 
vention. With the ever increasing emergence of new sen- 
sors, interfaces and mobile devices, the grand challenge is 
to keep up with this race in developing software drivers and 
wrappers for IoT things. In this paper, we examine the 
approaches that automate the process of developing mid- 
dleware drivers/wrappers for the IoT things. We propose 
ASCM4GSN architecture to address this challenge efficiently 
and effectively. We demonstrate the proposed approach us- 
ing Global Sensor Network (GSN) middleware which exem- 
plifies a cluster of data streaming engines. The ASCM4GSN 
architecture significantly speeds up the wrapper develop- 
ment and sensor configuration process as demonstrated for 
Android mobile phone based sensors as well as for Sun SPOT 
sensors. 
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1. INTRODUCTION 

The term Internet of Things (IoT) was firstly coined by 
Kevin Ashton 3 in a presentation in 1998. Further expand- 
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ing this idea, the European Union has defined the above vi- 
sion as "The IoT allows people and things to be connected 
Anytime, Anyplace, with Anything and Anyone, ideally us- 
ing Any network and Any service [12]". It is expected that 
50 to 100 billion devices will be connected to the Internet 
by 2020. According to the BCC Research 4 , global market 
for sensors was around $56.3 billion in 2010. In 2011, it was 
around $62.8 billion. Global market for sensors is expected 
to increase up to $91.5 billion by 2016, at a compound an- 
nual growth rate of 7.8%. The connection and configuration 
of these sensor devices are not feasible to be done manually. 
Automation is essential to achieve the vision of IoT. This is 
the challenge we have addressed. 

There is an increasing trend of developing middleware so- 
lutions in order to connect sensors and actuators to the In- 
ternet. These middleware solutions support fast and simple 
deployment of sensor networks. GSN [T]. Sgroi et al. [24], 
Hourglass [25], HiFi [§], IrisNet [To], and EdgeServers [22] 
are some of the major middleware solutions. These systems 
share a common objective with minor differences in features 
and functionality. The GSN solution provides advanced and 
sophisticated functionality. Therefore, we decided to use 
GSN as the sensor network middleware to exemplify our 
proposed solution. 

One of the major drawback in these existing middleware 
solutions is connectivity and configurability. Sensors come 
with APIs that provide software interfaces to retrieve sensor 
data to the middleware solutions or applications. Different 
middleware solutions use different mechanisms to retrieve 
data from sensors. The solutions are referred using different 
terms such as wrappers, gateways, handlers, proxies, media- 
tors, etc. For example, GSN has a concept called Wrapper 
1 . Each sensor should have a supported wrapper to be at- 
tached to the GSN server, in order to communicate with the 
sensor hardware. These wrappers need to be developed man- 
ually. This is an overwhelming task. There are many sensor 
devices and smart objects [16] that come to the market reg- 
ularly. Therefore, developing wrappers or similar solutions 
manually is not a scalable and feasible approach. Thus, we 
investigate the methods that can significantly automate this 
process. 

The rest of the paper is organised as follows. Section [2] 
presents an overview on sensor networks. Section [3] describes 
Global Sensor Network (GSN) middleware in brief. GSN 
wrapper is briefly discussed in Section [2] The life cycle of 
the wrapper is presented in Section[5] Section [6] explains the 
problem that we have addressed in detail. Our proposed so- 



lution is presented in detail in Section [7] The Sensor Device 
Definition (SDD) files are explained in Section [8] Section [9] 
presents the experiment of connecting Android mobile de- 
vices to GSN. Finally, Section [10] presents the related work 
and is followed by a conclusion. 

2. SENSOR NETWORKS 

Sensor networks are the major enabler of the IoT. A sen- 
sor network [5] comprises one or more sensor nodes which 
communicate between each other using wired and wireless 
means. Each sensor node has the capability to sense, com- 
municate and process data. In sensor networks, sensors can 
be homogeneous or heterogeneous. These sensors are de- 
ployed in densely manner around the phenomenon which we 
want to sense 12]. These sensor nodes are typically low-cost 
and small in size that enable large deployments. 

Today, increasing number of mobile sensors becoming avail- 
able in the market as well as in sensor network deployments. 
Mobile sensors are capable of sensing while moving from one 
location to another. They add more efficiency and accuracy 
to the sensor networks, because a single mobile sensor can 
sense a larger area than a static sensor. Sensors built-in to 
the mobile phones can behave as mobile sensors and make a 
significant contribution in community sensing. For an exper- 
iment, we connected a mobile phone to the GSN to collect 
data via built-in sensors using manual wrapper development 
approach. We were able to identify the difficulties and chal- 
lenges related to manual wrapper development approach as 
presented in Section [9] We proposed our ASCM4GSN ap- 
proach to mitigate these difficulties. 

Before IoT, sensor networks have been used in domains 
such as health, military and home [2]. Today, sensor net- 
works and IoT share substantial amount of similarities. How- 
ever, most of the sensor network researches have been fo- 
cused on low level design and deployment issues. For exam- 
ple, fault tolerance, scalability, production cost, hardware 
constraints, sensor network topology, environment, trans- 
mission media, unpredictability, heterogeneity, energy effi- 
cient counting, localisation algorithms and power consump- 
tion are some of the leading research areas in the sensor net- 
works [5] [5] [14] [l5] . High level research areas such as data 
fusion and processing, have gained significant attention only 
in recent years. 

Sensor network deployment has been considered as a dif- 
ficult task in early days due to the heterogeneity of sensors. 
Developers and engineers had to deal with low level pro- 
gramming tasks in order to connect these sensor nodes to- 
gether and get the sensor data into applications. A number 
of frameworks and middleware solutions have been devel- 
oped in order to make this process easier. Global Sensor 
Network (GSN) [23] is such a middleware solution that en- 
ables zero-configuration deployment. It is used widely in 
over ten EU/ Swiss funded research projects [TT] . Figure [I] 
summarises our discussion and shows how the components 
we discussed above fit in real world. The next section intro- 
duces the Global Sensor Network (GSN) middleware. 

3. GLOBAL SENSOR NETWORK 

The Global Sensor Network (GSN) [l] [23] is a platform 
aimed at providing flexible middleware to address the chal- 
lenges of sensor data acquisition, integration and distributed 
query processing. It is a generic data stream processing en- 



gine. GSN has gone beyond the traditional sensor network 
research efforts such as routing, data aggregation, and en- 
ergy optimisation. The design of GSN is based on four ba- 
sic principles: simplicity, adaptivity, scalability, and light- 
weight implementation. GSN simplifies the process of con- 
necting heterogeneous sensor devices to applications. Specif- 
ically, GSN provides the capability to integrate, discover, 
combine, query, and filter sensor data through a declarative 
XML-based language and enables zero-programming deploy- 
ment and management. The above reasons lead us to choose 
GSN as our sensor network middleware over other alterna- 
tive solutions. 

The GSN adopts container based architecture. A detailed 
explanation is provided in 1 . Virtual Sensor is the key 
element in the GSN. A virtual sensor can be any kind of 
data producer, for example, a real sensor, a wireless camera, 
a desktop computer, a mobile phone, or any combination of 
virtual sensors. Typically, a virtual sensor can have multiple 
input data streams but have only one output data stream. 

A Wrapper is a piece of code that does the data acqui- 
sition from a specific type of sensor device. The GSN is 
capable of retrieving data from various data sources. Wrap- 
pers transform the raw data into the GSN standard data 
model that can be queried and manipulated later. All the 
wrapper classes need to extend the Abstract Wrapper class. 
Typically, third party libraries are initialised in the wrapper 
constructor. Each sensor needs to have a specific wrapper 
that can be used to retrieve raw sensor data. In order to 
connect a Mica2 [7] sensor, for example, the GSN should 
have a corresponding wrapper that can talk to Mica2 sen- 
sor and retrieve data from it. Currently, the GSN provides 
wrappers for all TinyOS [27] based sensors, RFID sensors, 
web cams, actuators, etc. Likewise, in order to connect an 
Android phone's built-in sensors to the GSN, it has to have 
a wrapper that can retrieve raw sensor data from Android 
phones. We discuss GSN wrappers in general and wrapper's 
life cycle in details in the next sections. 

4. GSN WRAPPER 

In this section, we discuss GSN wrappers. As we explained 
earlier, each and every sensor that needs to be connected to 
GSN should have a corresponding wrapper. The Figure [2] 
depicts a basic code structure for a GSN wrapper. 

public class EmptyWrapper extends AbstractWrapper { 
public boolean initialize ( ) { A 

} A 

public void run ( ) { |j> 
while ( isActive( ) ) { 
} 

} f% 

public DataFieldQ getOutputFormat (){..}" 

public String getWrapperName( ){....} Q 
public void finalize () {....} © 

Figure 2: GSN Wrapper 

All the wrappers need to extend the Java class 
gsn. wrapper. AbstractWrapper. Therefore, all the wrappers 
are subclasses of AbstractWrapper. There are four methods 
that need to be implemented by the subclasses. Those meth- 
ods are numbered 1-4 in the Figure [2] The methods are 1. 
boolean initialise(), 2. void finalise (), 3. String getWrapper- 
Name(), and 4. DataField[] getOutputFormat () . 
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A new thread is created for each wrapper in GSN. After 
creating the wrapper object, initialise () method is called as 
shown as (1) in Figure [5] All the communication using third 
party libraries should happen within this method. For ex- 
ample, a camera wrapper may talk to a third party API in 
order to talk to the camera and retrieve the camera images. 
In an AndroidWrapper, initialise() method creates a socket 
and waits until the client mobile phone sends the data pack- 
ets. 

The method finalise() is called at the end of the wrapper's 
life cycle. This method can be used to close all the connec- 
tions that established with the outer world by the wrapper. 
Concretely, all the resources acquired during the initialise () 
method should be released here. For example, in the An- 
droid wrapper, all the client communication resources such 
as sockets and ports are released in this method. 

The method getWrapperName() returns the name of the 
wrapper. The method getOutputFormat() returns a DataField 
object that provides a description of the data structure pro- 
duced by the wrapper. The run() method is responsible for 
retrieving sensor data from sensors and transform them into 
GSN data model. All the sensor specific API calls need to be 
done inside this method. This is the most complex section 
of the class. The content of this method is hard to generate 
automatically due to third party library dependencies. The 
auto generation of GSN wrappers is discussed in Section [7] 

5. GSN WRAPPER'S LIFE CYCLE 

The life cycle of a wrapper begins with the initiation of 
Virtual Sensor Definition (VSD) [H] file. When a user de- 
fines a VSD file, it triggers the virtual sensor creation pro- 
cess. This process triggers the specified wrapper to be gen- 
erated. 

<virtual-sensor name=" And roidHandler80" priority="10"> 



</source> 



</st ream> 
</st reams> 
</virtual-sensor> 



Figure 3: Virtual Sensor 

The wrapper that corresponds to each stream source (i.e. 
sensor) is defined under the address element in the VSD 
file. For example, the VSD file segment depicted in Figure 
[3] triggers the SunSPOT [l9] wrapper to be instantiated. 
Virtual sensor creation process sends a Wrapper Connection 



Request (WCR) to the wrapper repository [TT] in the GSN 
server. A Wrapper Connection Request is an object which 
contains a wrapper name and its initialisation parameters 
as defined in the Virtual Sensor. Sequentially, the following 
steps are followed: 
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Figure 4: Wrapper Life Cycle 

First, wrapper repository looks for a wrapper instance 
that matches to the WCR. If found, then the stream-source 
query will be registered with the wrapper and returns true. 

If there isn't any wrapper object that matches WCR in the 
repository, the wrapper repository generates a new appropri- 
ate wrapper object. Then, the newly created object would 
be added to the wrapper repository. Finally, the stream- 
source query will be registered with the wrapper and returns 
true. 

If there isn't any wrapper object that matches WCR in 
the repository and wrapper repository does not have an ap- 
propriate wrapper class to be instantiate, then returns false. 
The virtual sensor loader fails to load a virtual sensor if at 
least one of the stream sources required by an input stream 
fails. For example, if user defines a virtual sensor as depicted 
in the Figure [3] and if the GSN wrapper repository does not 
have a SunSPOT wrapper, then the virtual sensor would 
fail. Figure [4] summaries the life cycle of the GSN wrappers. 
We proposed to extend this process in our solution. The 
details are explained in Section [7] 

6. THE CHALLENGE OF IMPROVING EF- 
FICIENCY IN CONNECTING THINGS 

We introduced the problem in brief in earlier sections. 
Let's discuss it in details. Almost all the sensors come with 
third-party libraries or API released by the sensor manu- 
facturer. If we want to retrieve sensor readings, we need 
to access the sensor hardware through these provided third 
party libraries. This stays true when we want to develop 
sensor networks using sensor network middleware solutions. 
For example, sensor network middleware solution such as 



GSN provides features such as window based continuous sen- 
sor data querying. In order to accomplish this task, GSN 
should retrieve sensor data from the sensor devices and or- 
ganise them according to GSN specific data model. Most 
of the sensor network middleware solutions are good at pro- 
viding high-level features such as querying which deal with 
internal data structure. However, the biggest problem is get- 
ting the sensor data from the sensor hardware devices into 
middleware solutions. This challenge has been addressed by 
different sensor network middleware solutions using different 
mechanisms. For example, GSN uses Wrappers to accom- 
plish this task. The Figure [5] shows the current GSN Data 
Acquisition Architecture. 




Figure 5: Current GSN Data Acquisition Architec- 
ture 

However, we identify two drawbacks in current GSN data 
acquisition architecture. First problem is that these wrap- 
pers need to be developed manually by the programmers. 
For example, if we want to connect a SunSPOT sensor into 
the GSN, developers have to develop a wrapper that is spe- 
cific for SunSPOT. This wrapper will use the libraries pro- 
vided by the SunSPOT manufacturer to talk to the SunSPOT 
sensor and retrieve sensor data. When the sensor devices get 
updated, GSN developers have to update these wrappers as 
well. That means developers have to keep on updating these 
wrappers. This process decreases the scalability and it also 
requires more effort and cost. 

The second problem is lack of code sharing. For example, 
one project may develop a wrapper for SunSPOT sensors. 
However, there is no mechanism to distribute this wrapper 
among other projects. The same wrapper may be developed 
by different project groups. It reduces the effectiveness and 
efficiency due to repetition. We have addressed these two 
issues, first by automating wrapper generation and second 
by developing a cloud repository. We discuss the details of 
our proposed solution in Section [7] 

Let us discuss some of the possible approaches that we can 
follow to solve the problem presented above. By evaluating 
several sensor devices and IoT middleware systems, it was 
understood that the method (steps) of connecting a device 
to an IoT middleware system is significantly similar. The 
most commons steps can be explained as bellow. 

• Acquire Manufacturers' APIs: As we mentioned 
earlier, each sensor device comes with an API. In some 
instances, APIs are common across all the sensors de- 
vices produce by the manufacturer. In other cases, 
APIs are strictly related to specific type of sensors. 
However, middleware system should use these APIs to 
communicate with the sensor devices. Therefore, the 
first step is to identify the path to the APIs. 



• Acquire System Configuration Details: Most of 
the IoT middleware solutions need system configura- 
tion details such as IP addresses, ports and protocols 
to communicate with the sensor devices. Sometimes, 
it is possible to identify these details automatically 
and otherwise users may need to enter them manu- 
ally. Therefore, identifying the machine specific and 
platform specific information is also a critical step. 

• Initiate the Data Structure: Every middleware main- 
tains its own data structure. Once the sensor devices 
are connected to the middleware, the data sensed by 
the sensors need to be stored in these data structures. 
Therefore, identify the required data structure and al- 
locate them is a major steps. 

• Initiate the Communication between IoT Mid- 
dleware and Sensor Device: The communication 
between a sensor device and a IoT middleware solu- 
tion usually starts by initiating the communication. 
The exact process could be varied among different sen- 
sor platforms. This initiation does not exchange any 
sensor data, but it opens and establishes the necessary 
ports and paths to proceed. This step also allocates 
the required resources and makes them ready for the 
data communication. This step further ensures that 
both sensor and middleware is ready to communicate 
between each other. 

• Data Communication: This is the most important 
step. Based on the communication path established 
in the previous step, the sensor and the middleware 
will communicate either in push or pull method. As a 
result, middleware will receive sensor data periodically. 
The IoT middleware can store the sensor data on the 
data structure which prepared in an earlier step. 

• Close the Communication and Release the Re- 
sources: All the connections established between the 
sensor device and the middleware system needs to be 
closed. Furthermore, the relate resources need to be 
released, so they are available for used by other oper- 
ations. 

We encapsulated these steps into five segments in the Sen- 
sor Device Definition (SDD) files as discussed in Section 
[8] After identifying these commonalities, we investigate the 
methods of simplifying the process of connecting the sensors 
to IoT middleware systems. 

Every IoT middleware has its own way of communicating 
with sensor devices. Mostly, there are dedicated handlers 
to accomplish this task. For example, in GSN, the han- 
dlers are called wrappers as discussed in Section [4] In other 
approaches, these handlers are called gateways, proxies, me- 
diators, etc. Furthermore, different technologies can also be 
employed to develop these handlers such as web services, 
RESTful APIs, native code, etc. From the previous work 
conducted by different researchers, it has been identified that 
native code gives better performance in term of scalability 
and efficiency compared to other technologies such as web 
services [21]. Therefore, we decided to use native code to 
develop the handler, in our case GSN's wrappers. 

The process of automated wrapper generation is depicted 
in Figure [6] Once we define a SDD file for a specific sensor 
as explained in Section [8] it can be used to develop wrappers 
for different IoT middleware systems. As we mentioned ear- 
lier, every IoT middleware has its own component similar to 



wrappers. We can combine the wrapper template of an IoT 
middleware and a SDD file to generate a Middleware specific 
wrapper. Wrapper template explains the basic structure of 
a wrapper such as functions, methods, data structures, etc. 
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Figure 6: The Wrapper Generation Process 

7. ASCM4GSN ARCHITECTURE 

The two main problems in the current approach are ad- 
dressed as follows. We propose Automated Sensor Config- 
uration Model For Global Sensor Network (ASCM4GSN) 
architecture to address these issues. We introduce a Au- 
tomated Wrapper Generation Layer. As the name implies, 
this layer automate the process of wrapper generation. The 
process can be explained as follows. 

As we discussed in Section [5] the wrapper generation al- 
ways begins with a Virtual Sensor Definition (VSD). When 
a VSD mentions a name of a wrapper that GSN currently 
does not have in the wrapper repository, first, GSN searches 
the Sensor Device Definition Local Repository (SDDLR) to 
look for a matching Sensor Device Definition (SDD) file. We 
discuss SDD file in detail in the next Section. For now, SDD 
file can be explained as a specification file that contains all 
the information that is required to generate a wrapper class. 

If Sensor Device Definition Local Repository (SDDLR) 
does not have a matching SDD file, GSN will automatically 
connect to the Sensor Device Definition Cloud Repository 
(SDDCR) and search for a matching wrapper definition file. 
If there is a matching SDD file, the GSN will fetch the 
SDD file and feed it to the Automated Wrapper Genera- 
tion Layer. This layer generates the wrapper class, compiles 
it, and pushes it to the wrapper repository. After that, the 
wrapper life cycle proceeds as explained in Section [5] Figure 
[7] shows our proposed architecture. 

If there isn't any SDD file in the Sensor Device Defini- 
tion Cloud Repository (SDDCR) for a specific sensor, then 
the developers may need to develop a SDD file based on 
the SDD specification. However, the developers can upload 
their SDD file to the cloud so other users do not need to 
develop it again. This approach saves time and cost. In the 
future, there will be increasing number of sensors available 
in the market. Our community based cloud approach would 
be ideal to deal with wider adaptation of IoT and sensor 
network deployments. 



4 



Cloud 



^ Sensor Device Definition 
) Cloud Repository (SDDCL) 



Sensor Device Definition 
File (SDD) 



Sensor Device 
Definition Local 
Repository (SDDLR) 



al a, 



Automated 
Wrapper 
Generation 
Layer 



■ 
■ 



Serial 
Connector 

1 

t 

Sink Node 



Base computer Running GSN 
Figure 7: Proposed ASCM4GSN Architecture 



There are many reasons to base our approach on SDD files 
rather than wrapper classes. We could also use direct wrap- 
per classes instead of using SDD files. The reason for adding 
extra step to our approach can be explained as follows. 

If we use a wrapper class, then it would be a platform 
specific such as Java, C#, etc. We keep SDD files platform 
independent or cross platform. Some sensor devices may 
need to be configured using machine specific details such as 
port numbers, IP address, etc. Editing a SDD file is a much 
cleaner and easier way compared to editing a class file. In 
future, software tools can be developed to make the editing 
significantly easier. In that case, designing tools to edit plat- 
form independent file is much easier than editing different 
class files written in different programming languages. 

At a later stage it may be required to combine SDD files 
with semantic technologies in order to make the automation 
more sophisticate. As we mentioned earlier, wrapper class 
also need to use third-party libraries which are developed by 
sensor device manufacturers (e.g. camera). If we based our 
approach on wrapper classes, then we may need to distribute 
the libraries with the class file as well. This could create 
licensing and legal issues. In SDD files, we only need provide 
the link to the libraries so IoT middleware can download the 
libraries from the sensor device manufacturers. 

The second problem we identified has been addressed by 
connecting GSN to the cloud. We developed a Sensor De- 
vice Definition Cloud Repository (SDDCR), which acts as a 
global repository for SDD files, so software developers and 
hardware manufacturers can upload SDD files to the cloud. 
This means if someone develops a SDD file for SunSPOT 
once, any GSN instance deployed around the world would 
be able connect SunSPOT sensors automatically using that 
SDD file. 

8. ASCM4GSN SENSOR DEVICE DEFINI- 
TION 

Sensor Device Definition (SDD) is an XML file which com- 
prises number of elements. Describing each and every sec- 
tions and elements of SDD is beyond the scope of this paper. 
Here, we describe how SDD works using a real world exam- 
ple. The left side of Figure [8] shows the SDD file which cor- 



<libraries-collection> 

<library package- name= "com. sun. spot. io . j2me . radiogram . *" 

source="http://gsncloud. com/libraries/ spotlib_common. jar 
platform="java" /> 
<library package - name= "om. sun . spot . peripheral . ota . OTACommandServer " 
source=' 'http://gsncloud.com/libraries/spotlib_device. jar 
platform-" java" /> 
</libraries-collection> 



1 



<data-structure> 

<data-field field -nar\e=" light" type="int" 

description="Presents the light sensor. "/> 
<data- field field -name- "temperature" type="int" 

description="Presents the temperature sensor. "/> 
</data-structure> 



<system-configuration class= "System" method-" set? roper ty" > 

<property name = ' 'SERIAL _ POR T ">/de v/ttyA CM1 </ proper ty. 
<system- configuration 



<connection> 

<prerequisites builder-c\ass="OTACommandServer" method-" 'start" > 

<parameters>null</poroweters> 
</prerequisites> 

connection -initiation builder -class="Connector" method="open"> 
<paraneters name=" scheme ">radiogram</parameters> 
<parameters v\av\e="HOST_PORT">65</ parameter s> 

</connection-initiation> 

<data - interface c\ass=" RadiogramConnection " method= "newDatagram ": 
parameters name="size" c\ass=" RadiogramConnection" 
method-' 'getMaximumLength ">10</ 'parameter s> 
</data-interface> 
</connection> 



<data-transformation> 

<data -retrieval class= "Rad i ogramConnec tion" me thod= "rece i ve "> 

parameters r\ame= "packet ">Datagram</ 'parameter s> 
</ data- ret rieval> 

<data-field field -name="light" class-' 'Datagram" method-' 'readlnt" '/> 
<data- field field- name=" temperature" class-' 'Datagram" method-' 'readlnt' '/> 
</data-transformation> 




Sensor Device Definition File 



import com . sun . spot . io . j2me . radiogram . * ; 
import com. sun. spot. peripheral. ota. OTACommandServer; 
import javax.microedition.io.*; 



public class SunSpotsWrapper extends AbstractWrapper { 



| private DataField[] collection 
new DataField( "light", "int" 
new DataField( "temperature" , 
new DataField("packet_type" , 



new DataField[] { 

"Presents the light sensor."), 
"int", "Presents the temperature sensor.") 
"int", "packet type")}; 



public boolean initialize() { 
^ ^System.setProperty("SERIAL_PORT" 



"/dev/ttyACMl"); 



| OTACommandServer. start(); 

,fCon = (RadiogramConnection) Connector. open( " radiogram: // : "+H0ST_P0RT) j 
rCon . newDatagram( rCon . getMaximumLengthQ ) ; 



lie void run() { 



rCon.receive(dg); 
light = dg. readlnt(); 
temperature = dg.readlntQ 



System-generated SunSPOT Wrapper 



Figure 8: Comparison of SDD File and System-generated Wrapper 



responds to SunSPOT sensor device. The right side of the 
figure shows the SunSPOT wrapper generated by the Auto- 
mated Wrapper Generation Layer based on the SDD file on 
the left. Please note that both files are used for demonstra- 
tion purposes and only contain major sections and elements. 

Even though we do not intend to explain each and every 
element in the two files, a high level explanation can be made 
as follows. In Section [6] we identified six major steps that 
are common across all the sensor platforms. After analysing 
the steps, we encapsulate them into five segments in the 
SDD file. The segments are marked 1 to 5 in Figure [8] 
The segments are libraries collection, data structure, system 
configuration, connection, and data transformation. 

The segment (1) contains all the libraries that need to be 
downloaded for GSN in order to compile the wrapper. It 
consists of package names and the sources where the files 
can be downloaded. This section can also be extended to 
add installation files. For example, if a specific sensor needs 
to install drivers on the GSN server, this section can provide 
the source link to download and install the driver automat- 
ically It also consists of platform information. As we are 
intended to make these SDD files platform independent, the 
parameters can specify which libraries are related to which 
platform (e.g. Java, .Net, C, etc.). 

The next segment (2) includes the information about the 
data structures. It can be used to provide all the informa- 
tion required by the GSN in order to create GSN data model. 
The sensor data will be stored in the data structure created 
in this segment. The segment (3) is dedicated to store sys- 
tem level configurations. There are configuration settings 
that need to be configured. The properties and values need 
be changed depending on the operating system. For exam- 
ple, serial ports are named as /dev/ttyACM in Linux and 



as COM in Windows. 

The connection segment (4) comprises the information re- 
lated four steps: initiate connection with the sensor devices, 
initiate data retrieval mechanisms, retrieve sensor data, and 
close connection. This segment would be a lengthy section. 
According to our preliminary investigation, most sensors do 
have these four steps. Final segment (5) is for the data trans- 
formation. The retrieved data packets need to be examined 
and extract the values from them. These values need to be 
stored in the data structure defined in the segment (2). 

If we consider the length and the complexity of the two 
files, it is true that SDD file is more lengthy and complex. 
However, we can easily develop a graphical user interface to 
produce SDD file very easily which will reduce and hide the 
complexity in major way 

9. ANDROID TO GSN CONNECTIVITY EX- 
AMPLE 

We evaluated the process of connecting sensors to an IoT 
middleware called GSN. AndroidW rapper was developed in 
order to retrieve sensor data from Android mobile phones. 
It was realised that each and every sensor should have a 
wrapper talking to a GSN server in order to collect data. 
Developing such wrappers is a time consuming and tedious 
job. It could take one or more days for a developer to develop 
a single wrapper for a specific sensor including the time that 
would take to familiarise with the specific sensor platform. 
Our ASCM4GSN approach drastically reduces the develop- 
ment time as the developer does not need to familiarise with 
the sensor platform in order to generate a wrapper using our 
approach. Figure [5] shows the client application we devel- 
oped and installed on Android mobile phones. It generates 
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Figure 9: Sensor Data Generator Application 

and sends sensor data packets to the AndroidWrapper in 
GSN. 

10. RELATED WORK 

We recognise two initiatives related to our work; Sen- 
sorML [6] and IEEE 1451 standards [26]. SensorML pro- 
vides functionalities such as describing sensors and sensor 
systems for inventory management and sensor discovery, de- 
scribing sensor geolocation of observed values, describing 
processes and observations, describing performance charac- 
teristics, describing processing and analysis of the sensor ob- 
servations, etc. IEEE 1451 standards are dedicated to stan- 
dardise the data communication among sensors, actuators, 
and related devices. In our solution, we are dealing with 
sensor installation and configuration challenge where both 
above initiatives do not explicitly address this challenge. 

Californium (Cf) CoAP framework 17 has proposed a 
thin server architecture to solve the problem of connecting 
heterogeneous devices from different manufacturers with di- 
verse functionalities to the Internet of things. Cf [17] puts a 
thin server in front of the device to work as a proxy. Thin 
server only provides a low-level API to the elementary func- 
tionality of a device. The client applications or IoT mid- 
dleware system can communicate with the device via the 
thin server using a RESTful API. All the functionalities are 
encoded as REST resources. 

However in this type of approach, the communication be- 
tween the thin server and the device needs be developed by 
the developers. This decrease the efficiency in connecting 
thing to the IoT. Furthermore, using a thin server could 
also raise issues in term of energy efficiency and commu- 
nication overheads, specially due to the magnitude of IoT. 
This approach will perform very well, if the device manu- 
facturer provides a RESTful API integrated to the device's 
software package itself. Further, this approach would be 
ideal for device manufacturers to be followed as a step for- 
ward in standardising the communication between devices 
and applications. 

Web Services Gateways l2l] is an approach based on Model 
Driven Architecture (MDA) and Device Profile for Web Ser- 
vices (DPWS). The focus is on connecting industrial devices, 
where the devices have a lifetime of often more than 40 years, 
to the client applications in IoT paradigm. They have de- 



veloped gateways comprises with web services that provide 
interfaces to access the devices. The web service are gener- 
ated automatically using predefined models. 

In [21] , performance evaluation results has shown that the 
approach is not scalable. The papers [2l] [l3] admit that 
the web services approach would perform less compared to 
native code approach. That is why we proposed a native 
code generation approach over other mechanisms. The na- 
tive code approach increases the node complexity and the 
web service approach limits the scalability. There is a trade 
of between the two. 

InterX [20] is a smart phone-based service interoperabil- 
ity gateway for heterogeneous smart objects. It employs a 
mediator gateway that can transform one protocol to an- 
other. For example, InterX enables the communication be- 
tween Bluetooth based smart object and UPnP based smart 
object via a gateway in runtime. 

In contrast, our approach is based on development time 
mediator. We use XML as the mediator to produce the 
native code that can establish the communication between 
IoT middleware systems and smart devices. Runtime media- 
tors give less performance due to communication overheads. 
Another difference is that InterX is focused on well recog- 
nised appliances such as digital camera, tv, video player, 
etc. In our approach, we focused on low level sensors such 
a SunSPOT, Arduio, and we also offer extensibility to facil- 
itate more low level sensors. 

Hydra p] is an IoT middleware that allows developers to 
incorporate heterogeneous physical devices into their appli- 
cations. The interaction between devices and the middle- 
ware are enabled though web services. Hydra is based on a 
semantic Model Driven Architecture for easy programming. 
This is similar to the Web Services Gateways [2l] approach 
we presented earlier. Even though the performance eval- 
uation of the Hydra middleware is not available in device 
connection perspective, the paper [2l] has raised the similar 
issues related to employing web services as the gateways for 
smart devices. 

uMiddle [l8] is a bridging framework that enables seamless 
device interaction over diverse middleware platforms. This 
approach is similar to the InterX [20]. uMiddle transforms 
one protocol to another in runtime. This middleware is fo- 
cused on the interoperability between popular protocols such 
as Bluetooth, UPnP, etc. In contrast, we are more concerned 
about connecting low level sensors to IoT middleware solu- 
tions. uMiddle have identified three essential requirements 
of an interoperability middleware platform; transport-level 
bridging, service-level bridging, and device-level bridging. 
We have also considered these requirements in our approach. 

11. CONCLUSION AND FUTURE WORK 

In this article, we propose and discuss the ASCM4GSN 
architecture and develop a specification that can be used to 
automate the sensor data acquisition and configuration pro- 
cess related to IoT middleware. We conducted our imple- 
mentation and experiments based on a popular IoT middle- 
ware platform called GSN. Sensor devices come with APIs 
that need to be used in order to retrieve sensor data from 
the sensor devices. For this, middleware has to be aware 
of sensor devices. Typically, sensor drivers/wrappers need 
to be developed manually by a programmer using the third- 
party libraries. This requires more time, cost and effort. We 
have demonstrated that automating the process of develop- 



ing sensor drivers/wrappers will improve efficiency and pro- 
ductivity. We introduced Sensor Device Description (SDD) 
specification to facilitate the automation. We have proposed 
an SDD sharing mechanism using a cloud repository to re- 
duce the repetitive work. Currently, SDD files can be used 
to generate wrappers for GSN. However, we intend to keep 
SDD file as a generic sensor device definition mechanism 
that would be independent from IoT middleware solutions. 

Our future research work aims at efficient and effective 
automation of connecting things to IoT middleware as well 
as incorporating generated extended functionality. We will 
combine context capturing and semantic data technologies 
with procesing of sensor data inside the wrapper itself. 
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